On Jan 25, 2008 6:38 AM, Freddie Unpenstein <[EMAIL PROTECTED]> wrote: > > Presumably, you'd make it visible when the underlying range widget complains > about being changed, and then hide it again after some timeout. >
that's what i am doing. the tricky part is how to draw the scrollbar right on top of the underneath viewport and the widgets contained in the viewport. > > What I'm trying to figure out, though, is how do you scroll a widget, if its > scrollbar only appears after the content has been scrolled?!? (And assuming > you don't have a scroll wheel on your mouse.) > i used some controls make by openmoko, the basic idea is to cover a eventbox onto the viewport, and the eventbox would steal the mouse event and handle the scrolling. > > Or are you planning to implement automatic click-and-drag scrolling for the > associated content somehow. And if you are, what happens if the content has > interactive widgets, or drag sources, or whatever else. > at least it works for labels and gtkentry, since press/release events will be passed to the widget. drag&drop will be in conflict but hopefully i can disable dnd later. > > And are you planning to have the scrollbar just float, or steal some size > from the widget as automatic scrollbars do at present? And then if it > floats, will the other scrollbar appear also so you can get to the content > now hidden? Or does the user just have to sit there and wait until it hides > itself again? And who gets to decide how long that is?!? > ideally the scrollbar should just float above the scrolled window. when it appears, user can just wait until it hides, the timeout will be pre-determined. > > Interesting idea... Though I can't imagine it being more useful, than > hindering, for most computer users. > it could be useful at least for mobile user. since the screen space is too small to hold the scrollbars all the time. > > > > What WOULD be useful, though, is two individual features; > > > > 1) A "click-and-drag scrolling" derivative of GtkScrolledWindow. I'd make it > a derrived widget, since I can't imagine how allowing contained widgets to > remain interactive could be useful, and an entirely separate widget states > that much better, plus keeps the two opposing logics clearly separate. > openmoko guys did a great job on this, check this out: http://svnweb.openmoko.org/trunk/applications/fingerscroll/?rev=2486#dirlist > > 2) A handle box type widget that hides its content until the mouse comes > near. This could be set to either float or inline. In float, you'd display > a grip-bar to let the user know that there's something there, and then pop-up > the contained widget over top (covering but not actually replacing the grip > bar) when the mouse comes near it. In inline, you'd replace the grip bar > with the contained widget while the mouse was in the vicinity, and swap them > back when the mouse moved away. > it would be better if both the scrollbar and the stuff in the scrollwindow can be display'd simultaneously, still does not figure out how to do it correctly. to float the scrollbar on the widget, the scrollbar can only be paint after all other widgets are repainted. i tried to postpone the scrollbar repaint event, it seems works. > > Inline mode here, should be easy (except, possibly, for the "in the vicinity" > part, if you wanted to allow a few pixels leeway). The underlying widget > would take care of the need to present the opposing scrollbar where needed. > In the float case, I suppose if you centered the contained widget (there > should be an alignment setting for this, though) over the grab bar, it would > work on that basis of "just deal with it". ;) > > > > The grip bar in either case would have a minimum size (that of a normal grip > bar, square), and would usually be extended to fit either horizontally or > vertically, by the widget it's embedded within (HBox, VBox, or > ScrolledWindow, etc.). The contained widget would, of course, would be > expandable similarly. > > > > > > I've got a helper function presently, somewhere, that adds click-and-drag > scrolling functionality to widgets. It'd be interesting to see it absorbed > into a real widget. Although I'd find the popup on mouse-near behaviour most > annoying personally. > > > > > > Fredderic > > _______________________________________________ > Join Excite! - http://www.excite.com > The most personalized portal on the Web! > > > _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
